1. Field of the Invention
The present invention pertains to a computer-implemented test tool.
2. Related Art Problem
Digital Cross Connects (DXC) are devices used in telecommunications networks to switch circuits by making internal logical connections between external physical ports. Cross-connects, disconnects, auditing, provisioning, and other actions are performed based on external commands issued by a control system.
DXCs are controlled by software, which is constantly being modified and upgraded to enhance the capabilities of DXCs. Each new software load must be tested prior to migrating into production. DXC testing is generally performed with a tool (computer) that emulates a control system by sending commands to the DXC and receiving responses from the DXC. The tool then reports results to user. Test scripts are commonly used to generate various commands in accordance with test scenarios.
Both physical and logical testing of DXCs are performed separately. Physical testing verifies that the electrical change of state that was requested of the DXC was actually performed. Logical testing verifies the actions imposed on the provisioned state of the DXC. Using both of these dimensions of testing, three types of tests are performed. Functionality testing is done by running a script once to test the functionality of the DXC. Stability testing is done by running a script multiple times to test the stability, in terms of predictability and repeatability, of the DXC. Stress testing is done by running multiple scripts over all resources to test the performance of the DXC under high volumes of transactions.
Since DXC software loads are frequent, a test tool is required that can be easily updated to test new functionality, stability, and stress requirements of DXCs. Current tools on the market perform the needed tests on DXCs, but have several limitations. Specifically, they:
Require extensive code in scripts. A typical script contains over 80,000 lines of code. This makes it difficult to update scripts for new software releases. For example, if a new release changes the syntax of a certain DXC command, each test script must be read line-by-line to change that command. PA1 Allow only one script at a time, for a single DXC, to be executed. This inhibits the capability to perform stability and stress testing. It also prevents multiple DXC testing, such as setting up a multi-DXC circuit for end-to-end testing. PA1 Support only a single RS-232 asynchronous interface for ASCII commands. This limits the throughput required for stress testing. It also limits the number of DXCs that can be tested to one, thus making it impossible to test end-to-end connections of multiple DXCs. PA1 Provide no automated means for testing the logical responses received from a DXC against the actual physical action performed. If a DXC responds positively to a "cross connect" command, a user must manually test the cross connect to see if it was actually performed. PA1 Provide no automated means for logically configuring the DXC. In order to perform meaningful tests, a test tool must place the DXC in a known logical configuration state. This requires the user to manually issue commands to the DXC to place it in a known state prior to testing. PA1 Provide no automated means for performing analysis of test results. All messages passed between the test tool and the DXC are recorded in a communications trace log. After a test is performed, the user must read through this log, which will contain hundreds of thousands of records for a typical test scenario, to determine results. PA1 Provide no means for remote control of the test tool. Users must have physical access to the tool to use it. PA1 Provide no means for interactive and dynamic script execution. PA1 Provides an improved method of testing with scripts, resulting in a reduction in the number of lines of script and an increase in the functionality of script commands. A 4000:1 or greater reduction in lines of script realized. The DXC Test Tool scripts utilize ranges, repeatable commands and pointers to data tables. Data tables specify which devices and ports to act on, thereby removing the need to use a separate command line for each device and port. The reduction of code allows modifying scripts for new software releases to be performed quickly and easily. PA1 Scripts arc repeatable and can be run in parallel. This allows stability and stress testing to be performed. Scripts can also be run for multiple DXCs simultaneously. This allows for multiple DXC control testing, such as end-to-end DXC testing, to be performed to simulate and detect real-world network events. Such events include setting up a multi-DXC circuit, knocking down a circuit, and outages, which are detected by alarm conditions transmitted through a network environment. PA1 Supports multiple interfaces of multiple types. Specifically, the DXC Test Tool supports both X.25 synchronous interfaces (for binary messages) and RS-232 asynchronous interfaces (for ASCII messages) for at least ten DXC devices and multiple TMUs, simultaneously. This greatly improves the stress testing capabilities of the invention. It also allows the invention to test end-to-end connections of multiple DXCs. PA1 Provides an automated method for testing the logical responses received from a DXC against the actual physical action performed. Before and after a command is sent to a DXC, the Test Tool requests a check on a cross connection from a TMU. The TMU responds to the Test Tool with indication as to whether a cross connect has been made or not. The Test Tool can then check if the response received from the DXC is accurate in reflecting the physical action performed by the DXC. PA1 Provides an automated means for logically configuring the DXC. The Test Tool has a database of DXC configuration files, which are input from the user. The Test Tool uses data from these files to generate and send commands to each DXC to configure it in a known state. Thus, when testing proceeds, appropriate results may be predicted. PA1 Provides an automated means for performing analysis of test results. During processing of a script, every command that is sent to a DXC has an expected response recorded. When the actual response is received, it is compared with the expected response. If they do not match, the actual response is recorded as an exception in an Analysis Log. Unexpected responses from the TMU, which indicate that a DXC did not perform the action that the DXC response message indicated, are also recorded as exceptions in the Analysis Log. All messages are recorded with a timestamp. The user may refer to the Analysis Log to identify all exceptions, and use the timestamp to refer to them in the Communications Trace Log. All records of both logs are organized into fields so that the user may apply filters to them to further reduce searches. This greatly reduces the time and effort needed to analyze test results. PA1 Provides remote control of the Test Tool so that users at distance locations may use it to perform testing. PA1 Provides means for interactive and dynamic script execution.
What is needed is an advanced DXC Test Tool for fully testing one or more digital cross-connect devices. Improvements in DXC level and inter-DXC level testing are needed. At the DXC level, a test tool is needed which can test all DXC ports including ASCII ports and fast channel ports. A test tool is needed for performing DXC testing in both logical and physical dimensions. The logical and physical response of a DXC to different commands needs to be verified. Logical responses such as solicited and unsolicited communication messages from a DXC need to be tested. Actions imposed by a DXC on provisioned states need to be verified. Physical actions at the DXC electrical interface such as changes in physical connectivity need to be verified. Functionality testing, stability testing, and stress testing needs to be performed more effectively and efficiently.
An inter-DXC level test tool is needed which can test the behavior of multiple DXCs simultaneously, as well as individual DXC performance. The configuration of paths through multiple DXCs needs to be tested. Logical and physical testing at the inter-DXC level is needed.